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1.  OBJECTIVE 


The  purpose  of  the  Final  Report  of  the  Computer  Family  Architecture  (CFA) 
Selection  Committee  is  to  make  available  the  details  of  the  considerable  work 
accomplished  by  the  Selection  Committee  during  its  evaluation  of  candidate 
architectures  for  the  Army/Navy  Military  Computer  Family. 

This  Selection  Committee,  representing  10  Army  and  17  Navy  organizations, 
was  established  by  the  Naval  Research  Laboratory  and  the  Army  Electronics  Com- 
mand as  a part  of  a joint  Army/Navy  effort  under  tne  Navy's  AADC  Computer  Family 
Architecture  Project  and  the  Army's  Fourth  Generation  Military  Computer  Family 
Project.  The  Selection  Committee  was  established  for  the  purpose  of  evaluating 
candidate  computer  architectures  and  recommending  one  as  the  basis  for  a family 
of  software-compatible  military  computers.  To  this  end,  the  Committee  worked 
from  October  1975  through  August  1976  and,  during  that  time,  held  five  full 
committee  sessions  lasting  several  days  each  and  numerous  other  subcommittee 
sessions,  leading  to  the  results  described  in  this  report. 

The  object  of  this  volume  of  the  CFA  Selection  Committee  Final  Report  is 
to  describe  the  rationale  and  motivation  behind  the  CFA  effort  and  the  organi- 
zation and  chronology  of  Selection  Committee  activity. 


2.  COMPOSITION  OF  REPORT 


This  report  details  the  work  of  the  Selection  Committee  in  approximate 
chronological  order.  It  is  divided  into  nine  volames  as  described  below.  A 
summary  volume  is  available  which  abstracts  the  entire  report. 

a Volume  I - Introduction  '-if,  ■•<ci 

Volume  I explains  the  background,  rationale  and  organization  of  the 
Computer  Family  Architecture  effort  ana  the  Selection  Committee. 

b Volume  II  - Selection  of  Candidate  Architecture  and  Initial  Screening 

Volume  II  describes  the  initial  candidate  selection,  and  discusses 
architectural  issues  pertinent  to  CFA  evaluation.  The  evaluation  criteria 
applied  to  the  architectural  candidates  for  preliminary  screening  are  de- 
scribed in  detail,  and  the  results  of  that  evaluation  are  discussed. 

E Volume  III  - Evaluation  of  Computer  Architectures  via  Test  Programs 

A - C ' ''  t 

Volume  III  discusses  the  development  of  the  measures  used  to  gauge 
architectural  efficiency  and  describes  the  test  programs  selected  for  the 
evaluation.  The  method  of  specifying  the  test  programs  and  the  structure 
of  the  programming  experiment  to  minimize  programmer  effects  are  also 
discussed. 

d Volume  IV  - Architecture  Research  Facility:  ISP  Description,  Simula- 
tion, Data  Collection 

Volume  IV  discusses  the  use  of  the  ISP  machine  architecture  description 
language  in  describing  the  candidate  architectures.  It  describes  the  ISP 
interpreter  facility  and  its  application  to  simulation  of  the  candidates  and 
in  gathering  the  measurements  discussed  in  Volume  III. 

6 Volume  V - Procedure  for  and  Results  of  the  Evaluation  of  the  Software 

Bases  of  the  Candidate  Architectures  for  the  Military  Computer  Family 

Volume  V describes  a menu  of  support  software  tools  determined  to  be 
important  to  the  development  of  military  software.  It  discusses  how  a sub- 
set of  those  tools  were  selected  as  the  necessary  software  base  for  the 
Military  Computer  Family  and  the  results  of  a study  to  determine  the  avail- 
ability and  value  of  these  tools. 

fi  Volume  VI  - Life  Cycle  Cost  Analyses  of  the  Computer  Family  Architec- 
ture Candidates 

/' 

Volume  VI  describes  the  methodology  used  to  compute  and  compare  the  life 
cycle  costs  of  the  CFA  finalists  and  describes  two  life  cycle  models  (top-down 
and  bottom-up)  and  the  results  of  applying  the  methodology  to  those  two  models 

^ Volume  VII  - CFA/Software  Licensing  Discussions  with  the  Three  CFA 

Finalists  (For  Official  Use  Only) 

Volume  VII  addresses  the  technical,  financial,  and  legal  issues  arising 
out  of  discussions  with  the  owner/manufacturer  of  the  candidate  computer  archi 
tectures  and  describes  the  outcome  of  these  discussions. 
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h Volume  VIII  - CFA  Final  Selection  ^ 1 

Volume  VIII  discusses  the  consideration  by  the  Selection  Committee  of  the 
results  of  the  architecture  evaluations  described  In  Volumes  II  through  VII  of 
this  report.  The  influences  that  the  various  results  had  on  the  final  selection 
are  described. 

1 Volume  IX  - A Consideration  of  Issues  in  the  Selection  of  a Computer  Family 

Architecture  >.  - 

Volume  IX  addresses  questions  and  controversial  issues  regarding  the  CFA 
Selection  process  that  arose  from  both  within  and  without  the  Selection  Committee 
during  the  course  of  the  CFA  effort. 
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3.  BACKGROUND 

Each  new  computer  type  added  to  the  military  complex  brings  its  own  unique 
requirements  for  system  interfaces,  logistics  support,  software  development,  main- 
tenance, and  training.  Over  a hundred  computer  types  can  be  found  in  military 
systems,  and  many  individual  platforms  such  as  aircraft  and  ships  can  be  found 
with  three,  four,  or  more  different  computer  types  aboard.  Heavy  penalties  are 
being  paid  in  terms  of  exploding  software  development  costs  and  high  life  cycle 
costs. 

These  costs  are  now  several  billion  dollars  annually  and,  relative  to  the 
computer  industry  at  large,  are  buying  inadequate  returns  in  terms  of  military 
systems  effectiveness  and  reliability. 

The  sources  of  proliferation  are  varied.  There  is  lack  of  opportunity,  lack 
of  incentive,  and  lack  of  control  which  would  promote  unified  software  and  hard- 
ware technology  in  military  systems.  Platform  managers,  under  pressure  to  meet 
project  cost  constraints  and  schedules,  must  rely  on  the  providence  of  a myriad 
of  industrial  firms,  who,  in  turn,  must  contend  with  their  own  profit,  performance 
and  schedule  problems.  As  a result,  computers  and  software  in  military  systems 
are  invariably  designed  or  chosen  on  the  basis  of  local  expediency  rather  than 
their  impact  on  long  range  life-cycle  costs.  Little  opportunity  or  incentive  for 
choosing  a standard  is  provided  to  these  platform  managers.  Nor  will  an  enforce- 
ment or  control  mechanism  be  truly  effective  until  an  attractive  set  of  standards 
is  available  from  which  to  choose. 

Computer  standardization  of  some  form  has  always  been  proposed  as  a 
solution.  But  past  standardization  efforts  in  the  military  centered  around 
hardware  designs  because  the  software  issues  were  less  apparent  than  the  logis- 
tics of  the  hardware. 

The  Navy  has  been  successful  at  utilizing  standard  hardware  for  computers 
(e.g.  the  UYK-7  and  UYK-20)  and  providing  some  centralized  acquisition  and  sup- 
port management  for  fleet  users.  Other  militarized  computers  have  been  used  by 
the  services  (e.g.  AN/UYK-19,  AN/GYK-12,  USQ-20,  AP-101)  in  sufficient  numbers 
and  with  enough  support  so  as  to  effect  a degree  of  defacto  standardization. 

Although  past  hardware  standardization  efforts  have  reduced  hardware  costs 
through  packaging  improvements  and  production/maintenance  economies  of  scale, 
no  similar  economies  of  scale  were  pursued  for  the  software  associated  with  the 
above  computers.  That  is,  software  that  was  already  developed  for  one  military 
computer  could  not  be  used  when  a newer  computer  model  was  brought  out.  So  called 
"families"  of  compatible  military  computers  were  compatible  in  packaging  charac- 
teristics only  and  required  separate  support  and  applications  software  developments. 
The  military  computer  market  provides  little  competitive  inducement  for  commercial 
firms  to  invest  in  support  software  development  for  these  computers.  As  a result, 
DoD  pays  over  and  over  for  development  of  computer  systems  that  frequently  fall 
short  of  expectations. 

Computers  that  became  technologically  obsolete  were  belatedly  observed  to 
have  large  investments  in  software  that  cculd  not  be  conveniently  discarded  and 
replaced  along  with  a newer  model  computer.  Indeed,  production  lines  for  old  out- 
of-production  military  computers  have  had  to  be  reopened  at  considerable  expense 
in  order  to  produce  very  costly  exact  copies  of  old  obsolete-hardware  machines 
because  there  was  no  other  satisfactory  way  to  duplicate  the  "software  execution 
characteristics"  of  the  originals. 
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However,  fn  the  last  few  years,  managers  In  DoD  have  become  painfully  aware 
of  the  ever  increasing  Investments  In  time  and  money  that  software  development  and 
maintenance  are  demanding.  A concept  Is  needed  which  will  provide  each  platform 
manager  with  the  computer  that  Is  right  for  his  particular  application  and  at  the 
same  time  will  provide  him  with  a mature,  complete,  and  well  developed  set  of  pro- 
gramming support  tools  (compilers,  debugging  aids,  editors)  and  an  established  base 
of  training  and  expertise  to  back  It  up. 


4.  CFA  APPROACH 


The  need  for  standardization  combined  with  the  variety  of  application  require- 
ments warrant  and  justify  a family  of  military  computers.  The  instruction-set 
architecture  of  the  computer  (that  which  programmers  need  to  know)  would  be  stan- 
dard, whereas  environmental  and  performance  parameters  would  be  allowed  to  vary. 
Indeed,  the  feasibility  of  such  an  approach  has  been  amply  demonstrated  by  the 
success  of  the  IBM  System  360/37U  and  the  DEC  PL)P-I1  systems.  The  hardware  imple- 
mentation varies  from  model  to  model,  ,)rovidinq  a range  of  cost  and  performance. 

The  architecture  remains  constant,  allowing  the  development  of  a single  common  set 
of  support  software  as  opposed  to  the  n sets  necessary  if  the  architecture  were 
allowed  to  vary.  Although  the  CFA  models  will  vary  along  yet  another  axis,  envi- 
ronment, the  same  basic  approach  (common  architecture/varying  hardware)  is  appli- 
cable and  will  be  successful  in  combating  unnecessary  computer  proliferation. 

It  is  reasonable  to  inquire  whether  a similar  approach  will  yield  similar 
results  in  the  weapon  system  environment.  There  is,  indeed,  sound  reason  to  be- 
lieve so,  because  the  weapon  system  computer  acquisition  and  life-cycle  process, 
particularly  in  the  software  acquisition  and  maintenance  phases,  does  not  differ 
significantly  from  the  commercial  process  (particularly  in  the  original  equipment 
manufacturer  (OEM)  market). 

a Computer  Industry  Precedent 

Any  consideration  of  promulgating  standards  for  military  computer  systems 
should  begin  with  a recognition  of  the  fact  that  the  commercial  computer  industry 
is  spending  over  one  billion  dollars  annually  for  R&D  as  opposed  to  less  than  100 
million  dollars  per  year  in  the  armed  services.  This  disparity  is  likely  to  in- 
crease in  the  future.  Those  developments  and  trends  that  have  survived  the  test 
of  the  mainstream  computing  industry  should  receive  serious  attention  as  candidates 
for  military  standardization  thrusts  for  two  reasons: 

(1)  Military  dollars  spent  on  adaptation  of  industry  standards  to  military 
systems  will  return  many-fold  in  capitalization  on  evolving  commercial 
i nvestments. 

(2)  Adoption  of  mature  and  successful  industry  developments  will  minimize 
the  risk  of  jumping  into  new  or  untried  approaches. 

The  Army/Navy  Computer  Family  Architecture  Program  is  designed  to  take  advan- 
tage of  several  proven  computing  industry  trends: 

(3)  A family  of  software-compatible  computers  in  a variety  of  hardware  and 
performance  packages  has  been  demonstrated  to  provide  a cost  effective 
means  of  serving  a growing  and  evolving  base  of  commercial  consumer  re- 
quirements while  constraining  support  software  development  to  the  re- 
quirements of  a single  architecture. 

(4) .  The  rapid  growth  of  digital  harcware  technology  has  been  largely  re- 

sponsible for  the  vast  improvements  in  computer  performance  over  the 
last  two  decades.  This  evolution  in  technology  is  expected  to  continue 
and  to  be  the  basis  for  continued  decreases  in  processor  price,  size, 
weight  and  power,  and  increases  in  pr-'cessor  performance. 


'c\  Microprogrammable  processors  in  modern  technology  embodiments  provide 
' flexible  and  effective  means  of  implementing  single  or  multiple  computer 


architectures.  IBM,  when  it  moved  its  mainstream  support  to  the  360 
family  of  computers,  continued  to  support  investments  in  existing  7090 
and  1401  software  through  emulation  of  the  older  computers  in  micro- 
programmable  360  processors. 

The  Military  Computer  Family  will  limit  variation  in  military  computer  systems 
where  it  can  and  should  be  limited  - at  the  software  interface  between  programmer 
and  processor  - and  will  allow  diversity  where  it  must  be  flexible  - in  the  tech- 
nology/performance areas  - and,  to  this  end,  will  capitalize  on  the  best  available 
industry  developments.  A family  of  software-compatible  computers  representing  a 
wide  variety  of  form,  fit,  and  function  capabilities  will  provide  ample  opportunity 
for  platform  managers  to  use  the  standard.  An  existing,  tested,  and  widely-supported 
base  of  processors  and  support  software  will  provide  his  incentive  for  choosing  the 
standard.  Enforcement  of  the  standard  will  be  viable  because  the  standard  will  be 
an  economically  viable  option. 

b.  Alternative  Levels  of  Standardization 

There  are  several  possible  approaches  to  lessening  software  costs  through 
standardization.  These  are: 

(1)  High  Order  Language  (HOL)  standardization  only  - no  computer  standardi- 
zation. 

(2)  Standardization  on  a single  computer  hardware  design  of  advanced  perfor- 
mance and  environmental  capabilities. 

(3)  Standardization  on  a single  computer  architecture  that  is  the  basis 
for  a software  compatible-family  of  computers  having  a variety  of  per- 
formance and  environmental  capabilities.  This  standard  architecture 
could  be  a new  design  or  an  existing  commercial  design. 

HOL  standardization  may  occur  along  with  (b)  or  (c)  but  is  not  a prerequisite 
for  (d)  or  (c). 

c.  HOL  Standardization 

Standardization  at  the  HOL  only  means  that  all  software  would  be  written  in 
certain  approved  high  level  languages  (e.g.  FORTRAN,  JOVIAL,  CriS-2,  COBOL)  but  that 
no  constraints  would  be  placed  upon  the  types  of  computers  procured  for  military 
systems.  Effectiveness  of  system  development  and  support  activities  would  depend 
upon  having  compatible  compilers  from  each  HOL  to  each  machine  instruction  set  and 
other  appropriate  support  software  associated  with  each  computer  type.  Direct  exe- 
cution of  intermediate  or  high  level  language  is  a possible  alternative  to  multiple 
compilers  and  assemblers,  but  only  if  there  is  agreement  on  a precise  description  of 
the  HOL. 

A possible  advantage  of  this  approach  is  its  minimal  impact  on  the  military 
computer  vendor  establishment  and  their  investment  in  marketing  an  ever  changing 
assortment  of  computers  and  software. 

The  disadvantages  of  standardization  at  the  HOL  only  are: 
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(1)  The  continued  existence  of  multiple,  support-software  systems  that  aggra- 
vate software  maintenance  and  logistics  problems. 

(2)  Incomplete  software  transportability  between  different  computer  types. 
Since  certain  HOL  concepts  are  inherently  machine-dependent,  no  truly 
machine-independent  high  level  languages  exist  for  applications  and  sup- 
port software  (e.g.,  compilers,  operating  systems).  Parts  of  operating 
systems  are  by  nature  machine  dependent  because  they  must  contain  fea- 
tures to  deal  efficiently  with  the  structure  of  a machine's  architecture. 
Even  applications  programs  written  in  what  are  frequently  thought  of  as 
machine  independent  languages  experience  subtle  machine  dependencies 
(e.g.,  character  manipulation,  integer  truncation,  floating  point  preci- 
sion and  exponent  scaling). 

(3)  Direct  execution  of  high  order  languages  has  been  in  R&D  for  a decade  or 
more  and  has  yet  to  become  a proven  mainstream  development.  The  military 
should  scarcely  attempt  to  jump  into  an  investment  that  the  industry  at 
large  has  not  adopted. 

(4)  The  continued  delivery  of  a variety  of  computer  types  into  the  military 
of  necessity  increases  the  variety  and  difficulty  of  hardware  maintenance 
and  logistics. 

d.  Computer  Hardware  Standardization 

Some  have  held  that  a single  computer  hardware  design  incorporating  advanced 
technology  and  architecture  would  be  able  to  provide  a standard  for  most  computer 
system  applications. 

The  advantage  of  this  approach  is  that  only  one  hardware  design  would  have 
to  be  developed,  manufactured  and  maintained. 

There  are  a number  of  disadvantages: 

(1)  A computer  based  on  a specific  hardware  design  will  of  necessity  be 
relatively  expensive,  slow,  large,  heavy,  or,  in  some  other  way,  un- 
suitable for  many  applications  as  compared  to  other  hardware  designs, 
especially  if  the  hardware  must  be  built  to  meet  all  existing  environ- 
mental requirements. 

(2)  Today's  advanced  technology  is  tomorrow's  out-of-production  technology. 
Note  the  rapid  turnover  in  digital  device  form,  fit  and  function  due  to 
LSI  technology. 

(3)  A standard  based  on  a hardware-level  (gate,  pin,  card,  etc.)  design  is 
very  difficult  or  impossible  to  multiple-source  due  to  differing  manu- 
facturing practices  among  vendors. 

e.  Computer  Architecture  Standardization 

Standardization  on  a computer  architecture  controls  the  interface  between  the 
programmer  and  the  computer. 

By  computer  architecture  we  mean  the  abstract,  functional  description  of  a 
computer  as  would  be  seen  by  a machine-level  programmer  - that  is,  everything  the 
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programmer  needs  to  know  to  write  programs  that  run  on  the  computer.  This  view 
of  the  computer  Includes  the  instruction  set,  registers,  interrupts,  and  memory 
address  space.  Architecture  does  n^  include  hardware  implementation  features 
such  as  cycle  time,  instruction  look-ahead,  memory  interleaving,  bus  width,  or 
cache  memory.  Hardware  design  issues  need  not  affect  the  software.  More  impor- 
tantly, a clear  and  clean  distinction  between  the  architecture  and  implementation 
details  allows  software  to  be  transported  between  computers  with  the  same  architec- 
ture, even  though  they  may  have  very  different  implementation  features. 

By  standardizing  on  architecture  in  this  way,  we  have  the  option  of  choosing 
different  hardware  implementations  according  to  the  best  technology  that  industry 
has  to  offer  while  maintaining  a consistent  and  well  known  interface  for  software 
development  and  execution.  With  a single  standard  architecture,  a program  (whether 
written  in  HOL  or  assembly  language)  that  runs,  for  example,  on  an  avionic  member 
of  the  computer  family  would  also  run  on  a different  hardware  (i.e.  ground)  ver- 
sion of  that  architecture,  albeit  faster  or  slower  depending  on  electronic  tech- 
nology differences.  In  addition,  the  support  software  available  for  developing 
and  testing  programs  for  the  avionic  computer  would  be  available  for  developing 
and  testing  programs  for  the  ground  computer. 

The  advantages  of  standardization  on  a family  architecture  are: 

a.  Software  transportability  between  members  of  the  family  is  provided. 

b.  One  support  software  system  can  serve  all  members  of  the  family.  In 
addition,  the  software  development  computer  itself  can  be  a member  of 
the  family. 

c.  Specification  of  the  standard  at  the  architecture  level  provides  a 
tried  and  proven  way  of  multiple-sourcing  different  hardware  versions 
of  the  software-compatible  computer. 

d.  Family  members  can  cover  a wide  range  of  applications  (microprocessor 
to  large  support  computer)  through  a variety  of  hardware  technologies 
and  design. 

e.  Evolution  and  enhancement  can  be  accommodated  through  technology 
improvements  and  architecture  extensions. 

There  are  three  possibilities  for  obtaining  an  architecture  on  which  to 
base  a family  of  computers: 

a.  Develop  a new  architecture. 

b.  Use  the  architecture  of  an  existing  military  computer. 

c.  Choose  the  "best"  architecture  from  among  existing,  proven  military 
or  commercial  designs. 

f.  Develop  New  Architecture 

The  military  should  not  attempt  to  compete  with  the  enormous  thrust  of  the 
industrial  mainstream  in  data  processing  developments.  Designing  a new  computer 
architecture  involves  enormous  capital  investment,  a long  development  cycle  with 
little  return  on  investment,  and  high  technical  risk. 
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Despite  these  obstacles,  little  is  apt  to  be  gained  from  developing  a new 
computer  architecture.  Over  the  past  decade  or  two  the  vast  majority  of  increases 
in  computer  performance  have  come  about  through  advances  in  technology  and  hard- 
ware design  features  and  not  through  changes  in  computer  architecture.  The  basic 
structure  of  general  purpose  data  processor  architecture  has  gone  through  no  radi- 
cal changes.  Many  so  called  advances  in  architecture  (e.g.,  cache  memory,  instruc- 
tion look  ahead,  and  pipelining)  are  really  advances  in  implementation  techniques 
for  increasing  speed  and  do  not  affect  the  architecture  or  software  interface. 

Such  advances  are  architecture  independent  and  can  be  incorporated  into  a computer 
without  affecting  software.  Any  architecture  chosen  for  the  computer  family  should 
be  able  to  support  future  improvements  in  architecture  capabilities  through  careful 
extensions  to  the  basic  instruction  set,  but  only  after  such  additions  have  been 
proven  through  test  and  experience.  Jumping  into  new  or  radical  architectures  is 
a risk  that  the  military  should  leave  to  the  computer  industry. 


Use  Existing  Military  Computer  Architecture 


Some  would  argue  for  choosing  the  architecture  of  an  existing  military  com- 
puter as  the  basis  for  the  Military  Computer  Family  on  the  grounds  that  existing 
investments  in  that  computer's  software  cannot  be  ignored.  If  it  can  be  shown 
that  the  investment  preserved  by  selecting  a particular  military  computer  archi- 
tecture is  greater  than  that  which  would  be  lost  to  users  of  a different  military 
computer  or  greater  than  that  which  would  be  gained  from  the  already  available 
software  base  of  an  existing  commercial  computer,  then  the  standard  should  be 
based  on  that  military  computer.  It  should  be  noted  that  military  computer  ar- 
chitectures are  not  unique,  in  that  military  data  processing  does  not  involve 
processor  operations  which  are  not  common  to  data  processing  in  general  In  fact, 
many  widely  used  military  computers  (e.g.  AN/UYK-7,  AN/GYK-12,  AN/UYK-15,  AN/UYK-i9, 
AN/UYK-20  and  the  IBM  "4  Pi"  series)  are  military  implementations  of  architectures 
related  to  prior  commercial  architectures. 

If  a military  computer  were  chosen  as  the  basis  for  a standard  family,  then 
the  same  problem  would  exist  which  would  have  to  be  faced  if  a commercial  archi- 
tecture were  chosen  - how  to  protect  investments  in  software  written  for  the 
military  computers  not  selected  as  the  standard.  That  is,  choosing  the  AN/UYK-7 
as  standard  would  still  leave  open  the  status  of  investments  in  AN/GYK-12, 

AN/UYK-15,  AN/UYK-19,  and  AN/UYK-20  software  and  the  IBM  API  series. 

h.  Use  Best  Existing  Military  or  Commercial  Computer  Architecture 

Opening  the  architecture  selection  process  to  all  existing  and  proven  com- 
puters, commercial  and  military,  provides  the  best  potential  benefits  with  re- 
spect to  all  factors,  including  hardware  and  software.  A selection  process  which 
considers  commercial  computers,  will  provide  the  widest  potential  benefits  from 
computing  industry  mainstream  developments.  Be  it  military  or  commercial,  a 
military  computer  family  should  be  based  on  an  architecture  with  the  best  proven 
track  record.  Given  that  the  architecture  of  a commercial  computer  is  selected, 
emulation  of  existing  military  computers  will  be  provided  in  the  advanced  hardware 
of  the  MCF.  Existing  investments  in  military  computer  software  will  not  be  lost. 
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5.  ARMY/NAVY  COMPUTER  FAMILY  ARCHITECTURE  PROJECT 

The  CFA  goal  is  standardization  on  the  best  available,  proven,  and  cost 
effective  computer  architecture  as  the  basis  for  a family  of  software-compatible 
military  computers. 

In  pursuit  of  this  goal,  a Memorandum  of  Agreement  (MOA)  was  signed  by 
Capt.  H.  B.  McCaulley,  (AIR-03)  Naval  Air  Systems  Command,  and  Col.  0.  L.  Lasher, 
Commander,  Communication  ADP  Lab,  Army  Electronics  Systems  Command  in  March  1975. 
This  MOA  formed  the  basis  for  a cooperative  development  of  a Military  Computer 
Family  through  the  joint  efforts  of  the  Navy's  AADC  Computer  Family  Architecture 
Project  and  the  Army's  Fourth  Generation  Military  Computer  Family  Project. 

This  effort  is  designed  to  provide  military  system  developers  with  an  avail- 
able, qualified  family  of  computers  and  associated  systems  and  support  software 
with  the  following  salient  characteristics: 

a.  Range  of  Application.  A high  level  of  cost-effectiveness  for  a wide 
range  of  military  computer  based- systems. 

b.  Life  Cycle  Cost.  A significant  reduction  in  life-cycle  cost.  The  cost 
savings  should  be  sufficient  to  justify  the  investment  on  a business- 
like basis;  i.e.,  the  return  on  investment  should  be  attractive. 

c.  Know-how.  Availability  of  a broad  base  of  programming  knowledge  and 
expertise  both  in  the  industry  and  military  establishments. 

d.  Software  Reliability.  Significant  improvement  in  software  reliability. 

e.  Software  Capture.  Provisions  for  capture  of  existing  military  computer 
applications  software  without  degradation  of  mission  performance  and 
with  little  or  no  reprogramming. 

f.  Size,  Weight  and  Power.  Significant  reduction  in  hardware  size,  weight 
and  power  through  application  of  modern  computer  technology. 

g.  Alternate  Suppliers.  Availability  of  multiple  alternate  suppliers  for 
each  computer  family  member  or  major  subsystem  so  as  to  ensure  reliable 
sources  at  reasonable  cost  via  competition. 

h.  Technology  Independence.  Maximum  independence  from  hardware  technology 
so  that  the  government  can  benefit  from  technology  advances  with  a mini- 
mum cost. 

The  state-of-the-art  computer  hardware  and  software  technology  will  permit 
the  achievement  of  these  goals  with  a reasonable  investment. 

a.  Multi-Service  Development 

The  Army  and  Navy  have  joined  together  in  a cooperative,  coordinated  devel- 
opment of  the  MCF.  The  advantages  of  this  approach  in  maximizing  government  know- 
how, minimizing  R4D  investment  and  recurring  cost  and  optimizing  industry  support 
are  readily  apparent. 
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b.  Army/Navy  Computer  Family  Architecture  Selection  Committee 

Representatives  of  a number  of  Army  and  Navy  R&D  organizations  were  assembled 
for  the  purpose  of  specifying,  evaluating  and  selecting  a computer  architecture  as 
the  basis  for  the  MCF. 

The  objective  of  the  MCF  is  to  serve  effectively  as  wide  a range  of  military 
applications  as  possible.  It  was  therefore  appropriate  and  necessary  to  bring  into 
the  architecture  selection  process  as  broad  and  expert  a knowledge  of  the  require- 
ments on  computers  in  military  systems  as  could  be  obtained  in  the  military  estab- 
lishment. Moreover,  the  combined  knowledge  of  a number  of  capable  representatives 
served  to  submerge  the  effects  of  individual  judgments  and  to  strengthen  the  valid- 
ity of  the  CFA  recommendation. 

To  this  end,  letters  were  sent  to  various  Army  and  Navy  laboratories, 
project  managers,  and  other  organizations  in  early  1975  requesting  those 
organizations  to  propose  computer  architectures  that  would  be  suitable  as  candidates 
for  the  MCF  and  to  nominate  representatives  to  the  CFA  Selection  Committee.  The 
Selection  Committee  convened  for  the  first  time  at  the  Naval  Research  Laboratory  in 
October  1975.  Table  5-1  shows  the  Committee  membership. 
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TABLE  5-1 


ARMY/NAVY  CFA  COMMITTEE  MEMBERSHIP 
ARMY  MEMBERS 


Organization 

Primary 

A1 ternate 

U.  S.  Army  Electronics  Command 

D.  Hadden/E.  Lieblein 

J.  Mercurio 

Project  Manager,  Army  Tactical 
Data  Systems 

A.  R.  DeNezzo 

ILT  R.  Atkinson 

Project  Manager,  Navigation/ 
Control  Systems 

2LT  N.  Herndon 

Satellite  Communication  Agency 

R.  Perle 

J.  Per rone 

Project  Manager,  Patriot  Missile 
System 

CPT  R.  Sabin 

R.  Flights 

U.  S.  Arruy  Computer  Systems 
Command 

MAJ  B.  Blood 

U.  S.  Army  Aviation  Systems 
Command 

W.  Klees 

U.  S.  Army  Missile  Command 

D.  Wise 

ECOM  Avionics  Laboratory 

H.  R.  Chambers 

PMO  MSCS 

Ft.  Monmouth,  N.  J.  07703 
AMCPM-MSCS-TM-F 

A.  Buray 

NAVY  MEMBERS 

Organization 

Primary 

A1 ternate 

Naval  Underwater  Systems  Center 
Newport 

T.  Conrad 

D.  Watson 

Fleet  Combat  Direction  Systems 
Support  Activity 

R.  G.  Estell 

Naval  Post  Graduate  School 

LT  B.  E.  Allen/ 

G.  L.  Barksdale 

Naval  Avionics  Facility, 
Indianapolis 

Dr.  J.  Chaney 

C.  Eckert 

Naval  Air  Development  Center 

C.  Mattes 

C.  Joeckel 

Fleet  Combat  Direction  Systems 
Support  Activity,  Dam  Neck 

J.  D.  Warner 

C.  D.  Upshur 
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Naval  Surface  Weapons  Center, 

Dahl gren 

W.  L.  McCoy 

E.  W.  Nichols 

Naval  Air  Test  Center 

J.  P.  Sharatz 

G.  S.  Ryan 

Pacific  Missile  Test  Center, 

Pt.  Mugu 

M.  Stevens/ 

P.  L.  Miller 

R.  Lindsey 

Naval  Undersea  Center 

J.  K.  Fogerty 

T.  L.  Cloer 

Naval  Electronics  Laboratory 

Center 

N.  L.  Tinkelpaugh 

Naval  Ship  Research  & Development 
Center 

L.  M.  Culpepper 

C.  M.  Chernick 

Naval  Underwater  Systems  Center, 
New  London 

A.  Clearwaters 

H.  Watt 

Naval  Surface  Weapons  Center, 

White  Oak 

Dr.  L.  Haynes 

Naval  Training  Equipment  Center 

C.  F.  Summer 

L.  Healy 

Naval  Sea  Systems  Command 

W.  H.  Hill 

Naval  Research  Laboratory 

S.  Fuller 
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c.  Candidate  MCF  Architectures 


The  Selection  Committee  formulated  a list  of  candidate  architectures  based 
on  proposals  from  the  member  organizations.  The  architectures  evaluated  by  the 
Committee  are: 

Interdata  8/32 
IBM  S370 

AN/GYK-12  (Litton) 

AN/UYK-7  (Univac) 

AN/UYK-20  (Univac) 

Burroughs  6700 
DEC  PDP-11/45 
AN/UYK-28  (ROLM) 

SEL  32 

d.  Selection  Committee  Procedure 

Volumes  II  through  VIII  describe  the  CFA  selection  process  in  detail.  A 
salient  aspect  of  this  selection  process  was  the  emphasis  placed  by  the  Selection 
Committee  on  establishing  evaluation  criteria  and  selection  techniques  based  on 
objective  technical  requirements  rather  than  on  subjective  feelings  or  instinct. 

The  intent  and  the  outcome  of  this  approach  was  to  build  a fully  auditable 
and  verified  trail  of  data  and  decisions  leading  to  the  CFA  Selection. 

In  pursuit  of  this  approach,  all  issues  and  data  used  by  the  Committee  in 
examining  the  architectures  were  subject  to  scrutiny  and  approval  by  the  Committee 
as  a whole.  All  decisions  and  results  were  accepted  or  rejected  by  a mandatory 
two- thirds  majority  vote,  where  each  represented  organization  exercised  one  vote. 

The  Committee  was  a working  committee.  Essentially  all  of  the  technical  eval- 
uations, development  of  critria  and  test  methodologies,  and  generation  of  reports 
were  performed  by  members  of  the  Committee.  Subcommittees  representing  nearly  all 
of  the  Committee  membership  were  responsible  for  the  results  contained  in  this 
report. 

Figure  5-1  illustrates  the  evaluation  process  employed  by  the  Selection  Com- 
mittee in  arriving  at  its  recommendation.  Volume  numbers  next  to  the  boxes  indi- 
cate the  volumes  of  this  report  describing  these  aspects  of  the  selection  process. 

e.  Selection  Committee  Chronology 

The  CFA  Selection  Committee  convened  five  times  between  October  1975  and 
August  1976. 
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BURROUGHS  B6700 
IBM  S370 
INTERDATA  8/32 
GYK-I2 
PDP-11 
ROLM  1664 
SEL  32 
UYK-7 
UYK-20 


Vol  III 


IBM  S370 
PDP-11 


INTERDATA 

PDP-11 


V32  (FIRST) 


Fiqure  5-1 . 


PDP-11  (FIRST) 

IBM  S370  (SECOND) 

INTERDATA  (THIRD) 

Selection  Committee  Procedure 
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f. 


Committee  Meeting  One 


[ The  Committee  convened  for  the  first  time  on  October  1 and  2,  1975,  at  NRL, 

Washington,  D.  C.  The  background  and  goals  of  the  CFA  project  were  presented  to 
[ the  Committee  representatives  as  well  as  initial  considerations  for  computer  archi- 

! tecture  evaluation.  Subcommittees  were  established  to  gather  data  on  the  candidate 

architectures  and  to  formulate  architecture  evaluation  criteria. 

1 

An  initial  list  of  architecture  candidates  was  considered  and  approved 
i by  the  Committee. 

g.  Committee  Meeting  Two 

The  second  Committee  meeting  took  place  on  December  3 and  4 at  USAECOM, 

Ft.  Monmouth,  N.  J.  The  Committee  considered,  revised,  and  approved  architec- 
ture evaluation  criteria  formulated  and  proposed  by  a working  subcommittee. 

These  criteria  were  to  be  used  by  the  candidate  architecture  subcommittees  to 
gather  data  on  those  architectures.  Also,  the  Committee  representatives  were 
to  weigh  the  evaluation  criteria  for  the  purpose  of  applying  those  criteria  to 
ranking  of  the  architecture  candidates. 

h.  Committee  Meeting  Three 

The  third  Committee  meeting  took  place  on  February  17-20,  1976  at  NAVP6SC0L, 
Monterey,  California,  and  was  devoted  to  reviewing  and  applying  the  results  of 
the  architecture  evaluation  criteria.  Quantitative  scores  compiled  for  each 
architecture  and  "absolute  criteria"  evaluations  were  used  to  select  architecture 
finalists  for  more  intensive  evaluation.  Subcommittees  were  then  established  to 
carry  out  these  final  evaluation  phases.  These  phases  included  test  program, 
support  software,  life-cycle  cost,  and  licensing/royalty  cost  evaluations. 

i.  Committee  Meeting  Four 

The  fourth  Committee  meeting  which  occurred  on  April  28  and  29,  1976  at 
NRL,  Washington,  D.  C.,  reviewed  the  results  of  the  final  candidates  selection. 

One  of  the  finalists  was  eliminated  as  a result.  Preliminary  reports  of  the 
finalists  evaluation  subcommittees  were  reviewed  and  approved. 

•i.  Committee  Meeting  Five 

The  fifth  and  final  Committee  meeting  took  place  on  24-26  August,  1976  at 
NUSC,  Newport,  R.  I.  At  this  meeting,  the  Committee  considered  and  reviewed  the 
results  of  all  architecture  evaluation  work  performed  since  the  first  meeting. 

As  a result  of  these  considerations,  the  Committee  voted  and  made  its  final  recom- 
mendations for  the  CFA.  Committee  members  were  organized  to  participate  in  the 
writing  of  this  CFA  Selection  Committee  Final  Report. 

k.  Selection  Committee  Structure 

The  Offices  and  Subcommittees  instrumental  in  carrying  out  the  v-jrk  of  the 
Selection  Committee  are  shown  in  Table  5-2. 
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TABLE  5-2 

ARMY/NAVY  CFA  SELECTION  COMMITTEE  OFFICES  AND  SUBCOMMITTEES 

Chainnan  Aaron  Coleman,  USAECOM 

Vice-Chairman  William  Smith,  NRL 

Secretary  William  Burr,  USAECOM 

Interdata  8/32  Subcommittee 
Bill  Burr  - USAECOM  (Chairman) 

Mark  Stephens  - PMTC 
Linwood  Culpepper  - NSRDC 
Forrest  Summer  - NTEC 

IBM  S370  Subcommittee 

A1  Clearwaters  - NUSC,  New  London  (Chairman) 

CRT  Paul  Sabin  - PM,  Patriot 
2LT  Nancy  Herdon  - PM,  NAVCOM 

Burroughs  B-6700  Subcommittee 
Dave  Hadden  - USAECOM  (Chairman) 

Bob  Perle  - SATCOMA 

Bob  Estell  - FCDSSA,  San  Diego  (replaced  D.  Hadden  as  Chairman) 

DEC  PDP-11  Subcommittee 
Dan  Siewiorek  - NRL/CMU  (Chairman) 

Jack  Chaney  - NAFI 
LT  Bill  Allen  - NPGS 
MAJ  Ben  Blood  - USACSCS 

NOVA/ROLM  Subcommittee 
Len  Haynes  - N$WC  (Chai rman) 

Tom  Conrad  - NUSC 

ILT  R.  Atkinson  - PM,  ARTADS 

AN/UYK-20  Subcommittee 
John  Sharatz  - NATC  ( Chai rman) 

AN/UYK-7  Subcommittee 

Henry  Hill  - NAVSEA  (Chairman) 

AN/GYK-12  Subcommittee 

Norman  Taupeka  - PM,  ARTADS 

SEL-32  Subcommittee 
W.  L.  McCoy  - NSWC,  Dahlgren 

Test  Programs  Subcommittee 
Bill  Burr  - U$a£C0M  (Chai rma n ) 

LT  Bill  Allen  - NPGS 
Mark  Stephens  - PMTC 
W.  L.  McCoy  - NSWC,  Dahlgren 
Forrest  Summer  - NTEC 
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Selection  Criteria  Subcommittee 
Sam  Fuller  - NRL/CMU  (Chairman) 

Len  Haynes  - NSWC,  White  Oak 
Doug  Wise  - USA  MICOM 
Bob  Estell  - FCDSSA,  San  Diego 
Norm  Tinkelpaugh  - NELC 

Subsetability  Subcommittee 
Harold  Stone  - ECOM/U.  Mass.  (Chairman) 

Bill  Burr  - USAECOM 
Dan  Siewiorek  - NRL/CMU 
A1  Clearwaters  - NUSC,  New  London 
Dave  Hadden  - USAECOM 

Final  CFA  Selection  Methodology  Subcommittee 
Bill  Smith  - NRL  (Chairman) 

Bob  Estell  - FCDSSA,  San  Diego 
CRT  Paul  Sabin  - PM,  Patriot 

CFA/Architecture  Licensing  Evaluation  Subcommittee 
A.  H.  Coleman  - USAECOM  (Chairman) 

Y.  S.  Wu  - NRL 

Bill  Smith  - NRL 

LTC  A.  Salisbury  - USAECOM 

Sam  Levine  - USAECOM 

Software  Evaluation  Methodology  Subcommittee 
Ed  Lieblein  - USAECOM  (Chafnnan) 

A1  Clearwaters  - NUSC,  New  London 
LT  Bill  Allen  - NPGS 
John  Sharatz  - NATC 
MAJ  Ben  Blood  - USACSCS 
Norman  Taupeka  - PM,  ARTADS 
Jim  Wagner  - USAECOM 

Architecture  Test  Subcommittee 
Sam  Fuller  - NRL/CMU  (Chairman) 

Len  Haynes  - NSWC,  White  Oak 
W.  L.  McCoy  - NSWC,  Dahlgren 
Bill  Burr  - USAECOM 
Lynn  A.  DeNoia  - NUSC,  New  London 
Dave  Parnas  - NRL/Darmstadt 

Auditor  for  Quantitative  and  Qualitative  Criteria  Evaluation 
Harold  Stone  - ECOM/U.  Mass. 


